home *** CD-ROM | disk | FTP | other *** search
- From: inf2gr04@informatik.uni-frankfurt.de
- Posted-Date: Wed, 6 Oct 93 8:38:48 MEZ
- Received-Date: Wed, 6 Oct 93 08:38:48 +0100
- Message-Id: <9310060738.AA22203@hptest.rbi.informatik.uni-frankfurt.de>
- Subject: Re: sleep() and device drivers ...
- To: mint@atari.archive.umich.edu
- Date: Wed, 6 Oct 93 8:38:48 MEZ
- Mailer: Elm [revision: 70.85]
-
-
- Not long ago I asked for a metod for device driver functions to decide,
- whether sleep() was interrupted by a signal or not.
-
- Finally I got a solution myself.
-
- The underlying question of the above is to decide, if a signal handler could
- have called the device's close() function thus kfree()ing an object the
- sleep()ing function is just operating on.
-
- To decide this we use a counter `intr' which is incremented every time the
- device drivers close() is called and an object is really freed
- (if fileptr->links <= 0):
-
- unsigned long intr = 0;
-
- long
- dev_close (fp, pid)
- FILEPTR *fp;
- short pid;
- {
-
- ...
-
- if (fp->links <= 0) {
- ++intr;
- /* free the data associated with the fileptr */
- }
-
- ...
-
- return 0;
- }
-
- Furthermore we use a new sleep() function, which looks like this:
-
- short
- isleep (queue, cond)
- short queue;
- long cond;
- {
- unsinged long ointr = intr;
- sleep (queue, cond);
- return (ointr != intr);
- }
-
- Isleep() will return true if there were any 'disposing' calls to
- dev_close() while sleep()ing in a device drivers function.
- If isleep() returns true, the function calling isleep() should
- not touch any objects that could be freed by calls to dev_close() and
- perhaps return whatever is equivalent to EINTR or ERESTARTSYS. Like this:
-
- long
- dev_read (fp, buf, buflen)
- FILEPTR *fp;
- char *buf;
- long buflen;
- {
- while (data not available) {
- if (isleep (IO_Q, (long)fp->devinfo)) {
- /* perhaps fp was freed, so we cannot
- reference it to see if data is available */
- return ERESTARTSYS;
- }
- }
-
- read the data into `buf';
- ...
- }
-
- I strongly suggest to change pipefs' device driver and all other devices
- drivers which tend to have the same problem in the described way, in order
- to avoid references to already freed memory.
-
- Perhaps we should implement ERESTARTSYS in the kernel. If a device
- driver function returnes this error code, the kernel should restart the
- system call, checking again the filedescriptors, etc. If they are still
- valid, perhaps the call can be completed this time without interrupts.
-
- Comments appreciated,
-
- -- Kay Roemer.
-
-